home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000207_misckit-reques…aska.et.byu.edu_Tue May 31 15:59:17 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  4KB
  1. Return-Path: <misckit-request@alaska.et.byu.edu>
  2. Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
  3.     id AA00648; Tue, 31 May 94 15:59:01 -0600
  4. Received: from yvax1.byu.edu by alaska.et.byu.edu; Tue, 31 May 1994 08:33:46 -0600
  5. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-8 #4169)
  6.  id <01HCZDXEYUZ49GV6L9@yvax.byu.edu>; Tue, 31 May 1994 08:30:54 MDT
  7. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-8 #4169)
  8.  id <01HCZDW23NQO019ZZB@yvax.byu.edu>; Tue, 31 May 1994 08:29:41 -0600 (MDT)
  9. Received: from YVAX2.BYU.EDU by alaska.et.byu.edu; Tue,
  10.  31 May 1994 08:23:49 -0600
  11. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-8 #4169)
  12.  id <01HCZDNPND68019YDO@yvax.byu.edu>; 31 May 94 08:22:57 -0600 (MDT)
  13. Received: from sxpo.fdn.org by yvax.byu.edu (PMDF V4.3-8 #4169)
  14.  id <01HCZDNCO29C019U0V@yvax.byu.edu>; Tue, 31 May 1994 08:22:52 -0600 (MDT)
  15. Received: by sxpo.fdn.org id AA24510
  16.  (5.65c8/IDA-1.4.4/FdN-1.0 for byu.edu!misckit); Tue, 31 May 1994 16:22:59 +0100
  17. Received: by improve.fdn.org (NX5.67d/Improve-1.0) id AA00426; Tue,
  18.  31 May 94 15:06:40 +0200
  19. Received: by folie. (NX5.67d/Improve-1.0) id AA00219; Tue,
  20.  31 May 94 11:20:04 +0100
  21. Received: by NeXT.Mailer (1.100.RR)
  22. Received: by NeXT Mailer (1.100.RR)
  23. Date: Tue, 31 May 1994 11:20:04 +0100
  24. From: Frederic STARK <fred@folie.byu.edu>
  25. Subject: Re: Requesting input for file (p.s.)
  26. To: misckit@byu.edu
  27. Message-Id: <9405311020.AA00219@folie.>
  28. Content-Transfer-Encoding: 7BIT
  29.  
  30. I agree with the File object approach for storing files, but I believe the FileSearch object is necessary to perform complex search.
  31.  
  32. I think it (File) could be implemented as a subclass of a more abstract class (something that could be called a GraphNode ?).
  33. So we could make directroy trees of filesystems or netinfo structures or anything else, just by subclasing.
  34.  
  35. The abstract class should be designed to nicely interact with interfaces object (as NXBrowser).
  36.  
  37. Here are several design for file manipulation
  38.  
  39. 1) (I did this one once. Worked pretty well.)
  40.  
  41. File ---> Directory
  42.  
  43.         File:
  44.         - Hold file system information (- lstat)
  45.         - and a boolean (- (BOOL)isDirectory)
  46.         Directory:
  47.         - returns YES for - (BOOL)isDirectory
  48.         - implements a '- (SortedList *)files'
  49.  
  50.   The problem (for me) with this design is that I don't find it easy to subclass it (For adding display capabilities or anything - like having a TIFFFileClass, an AppWrapperFileClass, a MyDocumentFileClass and so one)
  51.  
  52. 2) If we could allow an extra pointer in the File object, for the SortedList holding the childs, we could merge File and Directory
  53.  
  54. 3) So, we could move the childs list pointer in an upper class to obtain
  55.  
  56. GraphNode ---> FileSystemNode
  57.  
  58. (Maybe spell 'FileSystemNode' as 'File' :-)
  59.  
  60.  
  61. The interface should/could contain this
  62.  
  63.  
  64. GraphNode:
  65.     - (BOOL)isLeaf;
  66.     - setLeaf:(BOOL)flag;
  67.     - childList;
  68.     - setChildList:(List *)childList;
  69.     - childListChanged;
  70.     - (GraphNode *)parent;
  71.     - setParent:(GraphNode *)aParent;
  72.         (...)
  73.  
  74. File:
  75.     + setDefaultFileClass:classId
  76.     - initFromPath:(const char *)path;
  77.     - initFromName:(const chart *)name inDirectory:(File *)d;
  78.     - (const char *)fileName;
  79.     - (const char *)fullPath;    // In a static buffer
  80.     - (FileError)lstat;
  81.     - isReadableFor:(int)ogo;    // Owner, Group, Other
  82.         (And so on)
  83.  
  84.         //    File System manipulation
  85.     - remove:(BOOL)force;
  86.     - recursiveRemove:(BOOL)force;
  87.     - moveToPath:(const char *)relativeOrFullPath;
  88.         (...)
  89.         
  90.         //    File Manipulation
  91.     - (int)open;        // Return new file descriptor
  92.     - (int)openOrCreat; // Next time I'll spell create with 'e'
  93.  
  94.  
  95. And somewhere we could define a FileSearch object, with another +setFileClass:classId.
  96.  
  97. The search methods would return a (File *).
  98.  
  99. For simple cases, we could implements the search methods as class methods in the File class (only one search active at a time).
  100.  
  101. For more complex search we could have a separate FileSearch class
  102. (Even subclass of SubProcess, for spawning a find ?)
  103.  
  104.  
  105.  
  106. Note 1:
  107.     This design is not designed to optimise space.
  108.     In fact, it is really expensive.
  109.  
  110. Note 2:
  111.     It should be interesting to have a possibility to create File trees from ls-lR, .bom, output of find and tar tvf files.
  112.  
  113. Note 3:
  114.     I am not yet familiar with the MiscKit, so excuse for all the (const char *) instead of MiscStrings and so on...
  115.  
  116. fred.
  117.